Part 8: FinOps Reporting and Dashboards

Probably want to also read "Envisioning Information" by Edward R. Tufte for more on this topic.

Main Idea

• Reports and dashboards are the user interface of FinOps and should be treated as production outputs.
• The way FinOps data is presented directly affects trust, decision-making, and adoption across the organization.
• FinOps reporting should be treated like a production product: clear, reliable, tested, and built for the people who need to use it.
• Reports can also be called dashboards or business intelligence, but the core idea is the same: they are the primary way people interact with FinOps data and insights.

Why This Matters

• Good reports do more than display data; they help people make decisions.
• Poor reporting creates confusion, weakens trust, and wastes time debating the data instead of acting on it.
• Effective FinOps reporting is a core part of enablement, not just a support artifact.

Core Concepts

• FinOps reports are a UX problem as much as a data problem.
• Reporting needs to tell a story, not just show charts.
• Data quality, consistency, and usability matter as much as raw data access.
• Reports should guide action for the intended audience.

Tooling Strategy: Native, Buy, Build, or Hybrid

• There is no single correct tooling path for FinOps reporting.
• Most organizations use a mix of tools that changes as maturity grows.
• Common approaches include:
  • native tooling - AWS, Azure tooling
  • SaaS FinOps platforms - CloudHealth, Cloudability, Apptio, CloudZero, etc.
  • buy then augment - add on custom reporting to a SaaS platform
  • homegrown tooling - building internal reporting systems using data from cloud billing and other sources

Using Native Tooling

Start here first, then evaluate if you need to buy or build additional capabilities.

• Native cost tooling is usually the right place to begin.
• It often provides enough capability for earlier FinOps maturity stages.
• Native tools also remain useful later as a sanity check and as a support reference with cloud providers.
• If native tools are not enough, figure out if you need to build or buy.

When Building Makes Sense

Building can make sense when the organization wants stronger control over its data and reporting model.

• Common reasons to build include:
  • control over your own data - not outsourcing
  • easier integration with internal systems
  • custom reporting needs
  • compliance requirements - SaaS might not have required compliance like SOC 2, HIPAA, or FedRAMP
  • pricing models that do not scale well with SaaS tools
  • strong in-house engineering and data capabilities

Questions to ask:

• How many people have accessed the platform in the past three months?
• What reports are regularly used?
• Which features are being used?

Findings:

• Native tools are preferred
• 10% of a platform's capability
• tailoring a custom application is difficult
• building is difficult, buying is faster

When Buying Makes Sense

Buying can make sense when the business wants faster time to value.

• Common reasons to buy include:
  • faster setup
  • built-in handling of complex cloud billing math
  • richer optimization features than native tools
  • access to specialized platform expertise and company support
  • better user experience and reporting design than what the organization can build on its own
  • less risk from changing to SaaS platform, cloud billing schemas and data quality issues

People and Process Still Come First

• Tools alone do not create a successful FinOps practice.
• Low adoption of a platform is often a people or process problem, not a tooling problem.
• A strong culture of cost awareness is required whether the organization builds or buys.

Reporting Is Operational Work

You should treat your FinOps reports the same way your engineering teams treat their production services, with controls, quality checks, and rigorous review. If your reports break or start presenting incorrect or even inconsistent information, then FinOps inside your organization is adversely impacted.

• Reports and dashboards should be managed like production systems.
• Any anomalies should be treated as bugs and fixed with the same urgency as production issues.
• Changes should be reviewed, tested, and rolled out carefully.
• Broken or inconsistent reporting damages FinOps adoption.

Data Quality Is Foundational

• Trust in reporting depends on trust in the data.
• Teams should treat reporting issues like production bugs.
• Quality checks, monitoring, alerting, and response processes are necessary to keep reports reliable.

Common Data Quality Problems

• Cloud billing data often arrives with delays.
• The latest one or two days of billing data may be incomplete or misleading. Clean up the last few days or maybe incomplete months.
• Cloud providers sometimes change billing behavior or schema in ways that break downstream custom built applications or scripts. This happens to me constantly.
• Queries can fail on edge cases such as date rollovers or missing values.
  • know the limitations of the queries you are running and the data you are using.
• When they don’t trust the reporting, not only can cost savings disappear but valuable engineering hours are also lost.

Two dates: Report last updated and how fresh the data is.

Practical Data Quality Guidance

• Consider trimming the most recent day or two of data when needed.
• Show both the report refresh date and the data freshness date.
• Monitor for incomplete or inconsistent data.
• Validate report logic over time, not just when it is first built.
• Alert users proactively when report quality is degraded.

Good Enough Beats False Precision - Perfect is the enemy of Good.

• Data quality does not mean perfect real-time precision to the smallest decimal.
• It means the data is consistently reliable enough to support sound decisions.
• The goal is trustworthy decision support, not impossible perfection.
• "Above all else show the data." —Edward R. Tufte

Report Tiering

• Not every report will be equally usefull or official.
• Some reports are managed production reports.
• Others are ad hoc or temporary reports created for a one-time question. Delineate vs Managed vs Unmanaged reports.
• Marking these clearly helps users know what they can trust and what is not maintained.

Why Tiering Helps

• It reduces confusion about which reports are authoritative.
• It helps prevent people from making decisions based on stale or one-off analysis.
• It encourages teams to rely on a smaller, curated set of production reports.

Keep the Official Set Small

• Mature FinOps teams may create many reports over time, but they should maintain a much smaller set of primary reports.
• These primary reports should answer the most important recurring questions. these may have different versions for different personas, but they should be consistent in definitions and metrics so you don't need to explain differences to different audiences.
• Old reports that no longer provide value should be retired, deleted, and scrubbed from existence.
• guiding users to reports and making sure they also know how to find them is also helpful.

Rolling Out Reporting Changes

• Production report changes should be staged before rollout in a dev environment or a dev report.
• Users should understand what changed, why it changed, and how to use the updated report.
• Report definitions and configurations should ideally be versioned so teams can restore a known good state if needed. CloudHealth doesn't have this, but it is a common feature in Power BI.

Avoid the Universal Report - the Single Pane of Glass

• A single report that tries to show everything usually becomes hard to read and hard to act on.
• Too much information weakens clarity.
• It is often better to split reporting into multiple focused reports that answer specific questions well.
• When designing a new FinOps report, try to keep it simple. Include only the required information.

Design Reports Around Questions

• Every report should answer a clear question. “What question am I trying to answer with this report?”
• If the report does not support a decision or action, it is probably too broad or too vague.
• Reports should provide only the information required for the next useful step.
• If you have to be there when your colleagues read your reports, then you will struggle to scale FinOps across your organization.

Use Layered Reporting

• High-level reports should provide simple summary views.
• Lower-level reports should allow drill-down into more detailed analysis.
• This helps users move from overview to detail only when they need it.

Accessibility and Usability

• Reports must be usable without the FinOps team standing beside every user to explain them.
• Good reporting design helps scale FinOps across the organization.

Visual Design Guidance

• Do not rely on color alone to distinguish data.
• Use patterns, line styles, or separate charts where needed.
• Keep related items visually close together.
• Place higher-level summary information above or to the left of detail.
• Maintain strong consistency across reports in layout, language, colors, and symbols.
• When you present savings as a green dotted line in one chart and then use a solid blue line for savings in the next, it won’t be clear to the reader that both represent the same thing.

Language Consistency Matters

• Use the same FinOps terms across reports.
• Avoid switching language between dashboards and audiences.
• Be specific about what terms like cost actually mean, such as amortized cost, unblended cost, or fully loaded cost.

Recognition Is Better Than Recall

• Users understand information more easily when related data is visible together.
• If people must remember context from another report or another screen, comprehension drops.
• Keep connected information within the same visual scope whenever possible.

Psychological Biases Affect Reporting

“Success in dealing with people depends on a sympathetic grasp of the other person’s viewpoint.” — Dale Carnegie, How to Win Friends and Influence People

• Reporting design can influence how people interpret information.
• The goal is not using these biases for manipulation but for better decision support.
• Understanding common biases helps avoid misleading designs.

Anchoring Bias

• Early information can anchor how users interpret everything that follows. Example: showing a team the most expensive services in the company before showing its own services may distort how that team judges its own costs.
• Reports should avoid irrelevant comparison points that bias interpretation.

Confirmation Bias

• People tend to favor information that supports what they already believe.
• Broad, overloaded reports make it easier for users to find evidence that confirms their current view.
• Focused reports reduce this risk by answering one question clearly. Example: a report that shows specific teams' cost and savings opportunities allows users to not compare against other teams or the company as a whole, which may lead to more accurate self-assessment and action.

Von Restorff Effect

The Isolation effect - what stands out is more likely to be remembered than what blends in.

• So....people are more likely to remember the item that stands out.
• Reporting can use this intentionally by surfacing the item with the most important change or risk.
• Example: showing fastest-growing cost items may focus attention better than only showing the largest current costs.

Hick's Law or Hick-Hyman Law

• More options increase decision time.
• Optimization reports should not overwhelm users with too many weak recommendations.
• Present fewer, stronger, and more actionable options to improve response rates.
• IF you can, show only one recommendation at a time, and then show the next one after the first is resolved.

Perspectives on Reports

Design for Personas

• Leadership reports should differ from engineering reports.
• Finance reports should differ from operational reports.
• Persona-specific reports are more effective than one report intended for everyone.
• Consistency in definitions and metrics across personas is still essential.
• If one of your reports is showing that a metric is off track, the other should reflect relevant opportunities for improvement of that metric.

Design for Maturity

• As FinOps maturity grows, reporting complexity will increase.
• More cloud services, more capabilities, and more measures of success will require more thoughtful reporting design.
• Reports should evolve as the organization's cloud and FinOps maturity evolves.

Design for Multicloud

• Separate cloud reports force users to make comparisons on their own.
• Normalized, combined reporting reduces confusion and makes cross-cloud analysis easier.
• As multicloud complexity grows, organizations often need tooling beyond native platforms - in house or 3rd party.

Put Data in the Path of each Persona

Page 206

• FinOps data should show up where people already work.
• Orphaned dashboards are underused.
• FinOps works better when cost data appears in existing workflows rather than in isolated reporting tools.

Data in the Path of Finance

• Finance should receive cloud spend data inside the systems and reporting patterns it already uses.
• This reduces friction and helps cloud spend fit into existing budgeting and audit processes.

Data in the Path of Leadership

• Leadership reports should connect cloud spend to business outcomes.
• Unit economic views help leaders understand not just cost, but value and impact.
• You should aim to provide unit economic metrics in leadership reporting that marry cloud spend to business metrics to showcase the value and impact of cloud usage to the business, not just the cost.

Data in the Path of Engineers

Cost is just another efficiency metric - but not if it is presented as a separate, interrupting activity.

• Engineers should see FinOps data in the same places they already see performance, reliability, and security metrics.
• Cost should feel like another engineering efficiency metric, not a separate interrupting activity.
• Embedding cost data into sprint planning and development workflows helps FinOps become part of normal engineering work. Note: Isolated FinOps data and conversations create cognitive load and distraction that invariably results in reactive cost work that occurs only when mandated. As a result, engineers will see FinOps tasks as interruptions to their work instead of being a part of it.

"We aim to output recommendations based on what our platform partners view as important to the platform. If we make a recommendation and the engineering team has a strong reason why they can’t do it, then we want that feedback loop to come back into our recommendations." Kim's quote from page 208 of the book.

Connect FinOps to Existing Reporting Teams

• FinOps teams should often partner with existing finance, executive, or engineering reporting teams instead of building everything alone.
• This improves consistency, reduces duplication, and increases adoption.

Seek First to Understand

• Optimization recommendations should start conversations, not accusations. Blameless culture is important here.
• Teams may have valid reasons for decisions that look inefficient from a distance.
• FinOps works better when it asks teams how they define efficient usage and then aligns reporting and recommendations accordingly.

Reporting Can Become Interactive

• FinOps reporting does not have to stay read-only.
• Over time, workflows such as approvals, exclusions, reconciliations, and allocation changes may become part of the reporting experience.
• This can make reporting more operational and more useful, but it also requires more capability and governance.

Strategic Lessons

• Reports are one of the most important delivery mechanisms in FinOps.
• Quality, consistency, and usability matter as much as the underlying data.
• Focused reporting beats overloaded reporting.
• Persona-based reporting is more effective than one-size-fits-all reporting.
• FinOps data becomes more powerful when it is embedded into existing business workflows.

Key Takeaways

• Treat FinOps reports and dashboards like production systems.
• Trust in reporting is critical to FinOps success.
• Start with clear questions and build reports that answer them directly.
• Avoid universal reports that try to do everything.
• Design reporting for the audience, the maturity level, and the workflows where action will happen.
• Put FinOps data where finance, leadership, and engineers already work.

Glossary

Term	Definition
Accessibility	Designing reports so users can understand and use them without needing constant help from the FinOps team.
Anchoring bias	A cognitive bias in which early information shapes how later information is perceived.
Build versus buy versus native	The strategic choice between using native cloud tooling, buying a platform, building internal tooling, or combining approaches.
Confirmation bias	A tendency to interpret or select information in ways that support existing beliefs.
Data in the path	The practice of putting FinOps data directly into the workflows and reporting environments users already rely on.
Data quality	The reliability, consistency, completeness, and trustworthiness of reporting data.
Delivered report	A report pushed to users directly, which must be especially concise and self-explanatory because it arrives without context.
Eyespan	The amount of information a person can compare within a single visual scope without needing to scroll or switch context.
Hick's Law	The principle that more choices increase decision time, useful when limiting optimization recommendations to the most actionable ones.
Managed report	An official report that is maintained, monitored, and intended to be trusted as part of the production reporting set.
Native tooling	Cloud-provider cost tools such as AWS Cost Explorer, Azure Cost Management, or Google Cloud cost tooling.
Operationalized reporting	Treating reports and dashboards like production systems with testing, controls, maintenance, and quality monitoring.
Recognition versus recall	A design concept that favors showing related information together so users can recognize patterns instead of remembering context from elsewhere.
Report tiering	Classifying reports by trust level, maintenance status, or purpose so users know which ones are authoritative.
Staging report	A non-production version of a report used for testing changes before they are rolled out to users.
Universal report	An overloaded report that attempts to show too much information at once and becomes difficult to understand or use.
Usability	The degree to which a report is easy, fast, and intuitive for its intended users.
UX of FinOps	The user experience created by how FinOps data is presented, navigated, and understood by different personas.
Visual hierarchy	The arrangement of content so users can easily distinguish summary information from supporting detail.
Von Restorff effect	The tendency to remember items that stand out from the rest, which can influence which data points users focus on.